Characters were built using 3D Studio Max 3.1 and textured with Photoshop.  Each character is about 1000 polys.  Roughly 750 for the body and 250 for head.  Character animations were done using Character Studio.

To maximize the re-use of assets characters in BC are built up from separate heads and bodies. Each are textured separately and physiqued on to the skeleton in such a way as to perfectly match their neck vertices. The neck verts of a particular body therefore have to match the heads that will be placed on it exactly. Be aware that this means not only the same position, but the same weights (physiquing) and they must be "locked". We call this process "Frankensteining", and the character scripts in scripts/Bridge/Characters determine how a character is made from its four pieces (head, head texture, body, body texture). To properly physique a body and head it makes sense to put them together in one model and physique it as one piece, then make two copies and delete either the head or body to create the two files. After they are separated they will have the same location and weighting, but still need to be locked individually.

Each character has two 256 x 256 textures.  The first one is for the head and hands. The second one is for the body. 4. Each character has three additional head textures for lip-syncing "a," "e," "u." According to our programmers, code has been written to accommodate the additional mouth shapes.  There are three additional textures for eye blinks. In the first two, the eyes are partially closed. In the third texture, the eyes are completely closed. Scripts in scripts/Bridge/Characters link these textures to the eye and mouth shapes.  

Animation of bridge objects (characters and chairs) was done by saving the animated object to its own file, animating it, then exporting the keyframe info in a NIF file. The object needs to be placed at coordinates world 0, 0, 0, with a corresponding dummy object in the bridge set that designates its actual position in the set.  We used three sizes of biped skeletons: small (small male, small female), medium (medium male, medium female), and large (large male, Klingons). We used a Ponytail bone as the mouth bone for jaw movement and pseudo lip-syncing.   All of the walks were position specific, while the turn and ambient animations were centered at (0,0,0). The get up and sit down animations were independent of the walk animations.  Most animations were built off of each other.  Artists would share and blend lots of animations when needed to create them. This is easy when using Character Studio's Motion Flow.  Some animations were position specific and had to be animated using the bridge model and saved in that exact location in World Space.

When an animiation is exported as a .nif it contains all the model and texture data of the model being animated. To slim this down to just the animation data (much smaller and more efficient) use the AnimOnly tool.

All BC character models are based on three skeleton sizes: Small (Female small, Male small), Medium (Female large, Male medium) and Large (Male large). We've provided these blank skeletons here to make it easier for mod makers to share our animations for completely new models.

Bridge models were built and textured in Max 3.1, much the same way as the ship models were. They were then brought into Lightscape (an architectural rendering program), which has a radiosity renderer that Max lacks. We were able to apply more realistic lighting than in Max, which allowed getting good vertex coloring and (with some specialized tools) generate light maps to be applied across sections of the model (floor map, wall maps, roof map, etc.). Theoretically you could use this to "bake" shadows into the existing texture maps, but this tends to make for large maps where you would be better off tiling a small map with a shadow pass separate. When bringing models into Lightscape, the bridge models had to be completely "bulletproof". That means no double faces, un-welded vertices, etc. Lightscape always seemed to find these glitches and magnify them since it tesselates the mesh when it renders and would produce some unpleasant results. It was not the most streamlined process, but the final results looked good. Many small and somewhat throw away tools were designed for solving minor problems on each of the bridges that looking back don't make sense to release. These tools had to do with the fact that Lightscape doesn't preserve the hierarchy of the Max model, and so we had to make a tool that took the heirarchy of a non-Lightscaped model and graft it onto the Lightscaped model exported as a hierarcy-less .nif file. There are also special organization issues and naming issues needed to get the lightmaps to dim and brighten for red alert lighting, as well as other maps to glow and flash (red wall lights).

Both bridges in the game were in the 4000+ poly range not including character and chair models.  We experimented with 2000, 3000, 4000 poly to get the best look and not over burden the graphics engine.  We don't recommend focusing on bridges for most mod folks as they were very difficult to do -- but would love to see what those dedicated fans come up with.

Texture Map dimensions are always factors of 2 (i.e. 4, 8, 16, 32, 64, 128, etc.) and were usually 256 x 256 in size. Also keep in mind that older cards can't support textures bigger than 256x256. The file format for all textures is TGA also known as TARGAs. The bridges generally used about 2 meg of total texture, and tended to use many small maps.

Ship Models:

Most ships had 3 different levels of detail, or LODs. As an example (look here), the Ferengi Marauder's poly counts were 248 polys for the low detail version, 928 polys for the medium, and 2843 polys for the high. If a model has more than one part (the Marauder has 3 pieces), all parts must have coincident centerpoints. Average polygon count on the models: Highest LOD: 2500 - 3000, Mid level LOD: 1000, Lowest: 200-300.

Mapping was generally done using Max's standard planar UVW mapping modifier (although other mappings are not excluded). Materials were usually "multi/sub-object" using Blinn shader type. Different map channels were used to map parts of the ship with different material IDs and/or UVW map modifiers.

Glows and enhanced glows are controlled with the textures' alpha channel. The lighter the alpha channel, the better lit the area. A good example for a map is: data\Models\SharedTextures\FedShips\High\Ent-D_Nacelle_glow.tga.

Enabling the glow maps is done by name matching. The actual strings to match are defined in the ship script file (which can be found in scripts/ships). As a convention, we used '_glow' to enable glows. This means that any maps used by a ship that contains '_glow' will have the light alpha regions always fully lit.

If you want different attenuation maps for specular highlights, a good example script is scripts/ships/FedOutpost.py. In this example it will use any texture that it can find that ends with _specular for the high and the mid level of detail.

You can also control the shininess for all the maps just by adding a "SpecularCoef" in the ships stats. scripts/ships/Sovereign.py is a good example, in that case it uses 0.5 (or 50%) of the specular highlights since it is already such a light ship.

The dynamic damage is also controlled by the ship script file. There are a few numbers that help control how much damage a ship will take before breaking apart those are the burn value and the hole value. Basically a ship will get progressively scorched up the burn value. Any damage above the burn value will display by default the skeleton texture (data/textures/effects/damage.tga). Higher values will result in a gaping hole. There is are ship modifiers that makes damage appear bigger and stronger on certain ships. This is useful on stations because otherwise you would almost never see the tiny specs of damage. To modify the damage radius, put an entry of "DamageRadMod" in the ship stats. To modify the strength put a "DamageStrMod" entry. You can find an example in scripts/ships/FedStarbase.py in the ship stats. In this case the damage volumes are 15 times bigger but only 0.06 (or 6%) of the usual strength.

The first time a ship is ever loaded in the game, a _vox.nif file is created in the same directory as the original .nif to keep track of the structure of the ship. This process can take some time on slower machines. Make sure to throw away any related _vox.nif if you modify a ship's geometry. Otherwise, you will have damage and structure based on the old model. Be aware that changing the voxel size of a model can result in huge voxel files if you make the resolution too high. While this might be good for the look of the damage, it will mean loads of RAM as well as load time and run time slowdowns. Note that stations have much larger voxels than ships because of their size, and compensate in their damage values.

Compiled by PL.  Version 1.0   March 14, 2002.

Contributors: 

• Richard Green
• James Therien
• Anthony Hon
• Victor Bennett
• Armand Cabrera
• David Litwin